1. Field of the Invention
This invention relates to computer systems and computer software, and more particularly to transaction management in computer-systems.
2. Description of the Related Art
Each application that runs on an application server may have an application state that includes data the application may use and/or change. The data defining the application state may be stored on data sources such as, but not limited to, databases. Operations used to modify data stored in the data sources may be grouped together in transactions. Transactions may have characteristics including, but not limited to, atomicity (either all of the operations in the group are applied to the data in the database, or none of the operations in the group are applied), consistency (the transaction is a correct transformation of the data in the database according to instructions executed by an application component), isolation (each transaction does not affect other simultaneously occurring transactions), and durability (if a transaction completes successfully, failures in an application component or database will not corrupt the transformation of the data in the database). After a transaction completes, the data in the data sources may be modified. If a transaction fails (e.g., is not completed), the data used in the data sources involved in the transaction may be rolled back to its pre-transaction state.
As an application starts, an application server may start a new transaction and open connections to data sources the application needs. When the application server opens a connection to a data source, the connection may be managed as a local transaction connection or a global transaction connection. A local transaction may involve a one-phase commit and may be used when an application needs one data source. A global transaction may involve a two-phase commit and may be used when an application needs two or more data sources. In conventional application servers, all transactions must be managed the same for any given instance of the application server, i.e., all local transactions or all global transactions.
Global transactions may be managed by a separate transaction manager in an application server such as a Java Transaction Services (JTS) manager. The global transaction may use a two-phase commit protocol. A global transaction may involve a transaction protocol such as the X/Open Distributed Transaction Processing XA standard from The Open Group vendor consortium. Before a global transaction is committed to its respective data sources (i.e., to modify respective data in the data sources), each data source involved in the global transaction may be asked to prepare to commit the transaction. If each data source is able to commit the transaction, each data source may send a signal to the transaction manager indicating so. After all of the data sources have indicated that they are prepared to commit the transaction, the transaction manager may send a signal to commit the global transaction.
Local transactions may be managed by a resource manager. Typically, a local transaction is performed in a manner specific to the data source. Local transactions (typically involving one data source) do not need to use the first phase of the global transaction two-phase protocol (i.e., asking if the data sources are prepared to commit the transaction). In a local transaction, if the data source is prepared to commit the transaction, the data source commits the transaction when the resource manager is instructed to by the application server. In general, a local transaction may be performed faster than a global transaction. Also, different data sources may have different capabilities. For example, if a data source does not support a global transaction protocol, then it may not be able to participate in global transactions.
After a transaction is committed, the transaction may be recorded in a transaction log to keep track of the transaction in case a data source fails during the commit phase. If a data source fails during the commit phase, the data source may be updated using the information in the transaction log. If a data source fails during the commit phase, the data source may request transaction information from the transaction log. The transaction log may send information for a committed transaction to the data source that failed during the commit to allow the data source to update itself.